-
Notifications
You must be signed in to change notification settings - Fork 607
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CL]: Export Position_lock_id mappings to GenesisState #4912
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggested changes. Please take a look and update the PR description
message PositionData { | ||
Position position = 1; | ||
uint64 lock_id = 2 [ (gogoproto.moretags) = "yaml:\"lock_id\"" ]; | ||
} | ||
|
||
// GenesisState defines the concentrated liquidity module's genesis state. | ||
message GenesisState { | ||
// params are all the parameters of the module | ||
Params params = 1 [ (gogoproto.nullable) = false ]; | ||
// pool data containining serialized pool struct and ticks. | ||
repeated PoolData pool_data = 2 [ (gogoproto.nullable) = false ]; | ||
|
||
repeated Position positions = 3 [ (gogoproto.nullable) = false ]; | ||
repeated PositionData position_data = 3 [ (gogoproto.nullable) = false ]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, it seems like the only reason we need to do this is because lock_id is the only externally linked data in all of the KVStore pairs. Maybe it makes sense for us to include underlying lock ID in the position struct after all...
Thoughts @p0mvn ? Just feels odd to make a new proto that links these two when it could just exist in the position struct itself. Not a huge deal tho
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did we remove it from the second index in the first place? Was it the fact that some position IDs don't have a lock id associated with them? If that's the case, I think the current approach is better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed it from the denom because of the complexity it introduced when attempting to create intermediary accounts with the base denom rather than the full denom (it would try and gather all locks with the base denom rather the full one). Also, removing it reduced much of the custom lock logic that was added previously
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will proceed with current approach and we can change anything that comes up in the future
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On glance the logic feels right, would like to hear what Roman has to say on moving lock to position struct before approving though. Nice work!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work
Closes: (#4875)[https://github.com//issues/4875]
What is the purpose of the change
(E.g.: This pull request improves documation of area A by adding ....
Brief Changelog
(for example:)
Testing and Verifying
(Please pick one of the following options)
This change is a trivial rework / code cleanup without any test coverage.
(or)
This change is already covered by existing tests, such as (please describe tests).
(or)
This change added tests and can be verified as follows:
(example:)
Documentation and Release Note
Unreleased
section inCHANGELOG.md
? (yes / no)x/<module>/spec/
) / Osmosis docs repo / not documented)